Software applications used to create and/or edit electronic content (referred to herein as “content creation applications”) use various techniques to store the electronic content that is being developed. Only the simplest content creation applications are able to store complete copies of content after every change. For example, a simple photo editing application might save a bitmap of pixel color values of an edited image after each change. This technique is only practical for electronic content that can be stored as a relatively small structure and in a context in which only a few changes are made. For more complicated electronic content and electronic content that involves many changes, implementing such a technique would require too much data storage to be practical or feasible.
Accordingly, many content creation applications use temporary memory to temporarily store incremental delta encoding in which changes are recorded and require the user to manually save the electronic content to more permanent storage. Typically, a user adds text, graphics, and other objects to a canvas area on the content development application and periodically saves the electronic content as a file, overwriting the previous version of the file. For example, a user may position several rectangles on a canvas, add labels to each of the rectangles, and then add arrows between the rectangles to create a flow diagram. The user then saves a file containing the electronic content to a local or network hard drive. While the user is editing the content, in between saves, changes that are made to the electronic content are stored in temporary memory and used to facilitate undo, redo, and other editing operations.
There are numerous disadvantages to the traditional technique of storing temporary changes to memory and requiring the user to periodically save the current version as a more-permanent file. With these techniques, users must manually save the files, which is inconvenient to many users. Moreover, if there is a system crash or similar problem, recent changes made since the most recent save are lost. In addition, the undo/redo features of these systems are limited to changes made during the current editing session, because edits from prior editing sessions were stored in temporary memory and lost when those editing sessions ended.
In addition to these disadvantages to the end users of the content creation applications, implementing undo/redo functions in these systems is burdensome on the developers who create the content creations application. This is because the developers must manually program the undo of any function that the developers program. For example, if a developer programs an “add rectangle” function, he or she must also program the undo of the add rectangle function. Similarly, implementing a delete function requires programming the delete but also accounting for what will happen if the delete is undone, e.g., requiring the programmer to store a copy of the deleted object in memory, its location, its size, its label, etc. To implement any new function, the programmer must thus also implement the undo of the function. This slows the development process down significantly and tends to introduce bugs that are difficult to find and correct.